一、项目目录

项目的构建方式大体上是普遍标准的模式,src 是业务开发目录,build 是构建后的目录。
构建工具采用 webpack+express 或 webpack+koa 的方式。
二、src 业务代码的设计

1.路由
这个不用多说,果断用 react-router 进行路由的控制。这里要对路由的构建目录特别说下:
- App.js 中列出项目中所有的路由。
- index.js作为项目的入口文件,只引用 App.js,以及其他 hack。
2.公共组件(components)
公共的业务组件统一放入 components 目录
注意
公共的含义是:多于一个页面用到的组件称为公共组件,如果只有一个页面用到的组件,不要放到 components 目录,放到对应页面的子目录。
3.高阶函数(hoc)
react 中有一个比较特色的功能,就是组件可以传入一个函数中生成新的高阶组件
常见的应用场景,通常是一些页面经常性的重复操作,可封装成一个高阶函数,进行统一处理,避免重复写代码
- 一些页面一进入就会去加载数据,此时便可使用高阶函数
- 如一些页面埋点的重复性操作
4.样式
项目中所有的样式都在 styles 目录下,该目录下的样式尽可能是公共组件的样式
如果某些页面需要使用样式,直接使用 react 内置的 style功能,这样可以尽可能保持目录的纯净度。
5.redux
如果需要使用 redux,可分为 store reducers action 三个目录进行控制
切记 ,要分清 redux 的应用场景,不要滥用
6.辅助工具(utils)
主要存放项目全局需要经常使用到的工具类
7.静态文件(data)
主要存放静态常量等
三、pages 目录
该目录与业务场景强相关,故在此先模拟个业务场景
1.业务背景
有三个角色 :角色 A、角色 B、角色O(管理员)
有3个业务场景:场景 I、场景 II、场景 III
其中,场景 I 只有角色 A 可以访问,场景 II 只有角色 O 可以访问,场景 III 所有角色均可访问
2.解决方案

角色和场景是一对一关系的时候,可以建以角色为根目录,场景为子目录的目录
其中场景 III index.js中,根据角色判断加载哪个角色的目录
角色和场景是多对一的关系的时候,可以建以场景为根目录,角色为子目录的目录。
3.业务组件
当页面中有该页面独有的业务组件时,请勿将其放入公共 components 组件目录,这样路径太远会不方便查找。
建议将该页面建一个目录,对应的业务组件放在该页面下

场景 I 的部分伪代码如下
|
|
这里有个小技巧
要充分利用目录下的 index.js文件,它作为目录的入口
比如当你遇到业务升级,增加新功能时,可以按上述方式将页面转成目录。

这样做的好处是:
import 时可以不用加./index.js
,不需要改import 的代码
|
|
四、redux
不要滥用 redux
项目中当需要全局使用到的变量等的时候,才需要用到 redux。
利用 redux 可以将这个变量注入到你需要注入的页面。
五、代码技巧
巧用export default
如
|
|
六、构建工具(webpack)
使用 webpack 配置时,有些小技巧可以分享
1.alias
开发时,引用其他目录的文件时,经常出现以下代码
|
|
当你的目录结构变动时,修改相对路径对你来说,无疑就是一场灾难
其实你可以这么干,指定绝对路径
|
|
然后你就可以
|
|
当 index.js 在目录中的位置变化时,你就可以不需要修改 index.js的任何代码了
2.external
为了避免react等基础库重复构建,可以利用 webpack的externals
参数,避免重复构建。
这样,您需要构建的代码就只有 src 目录下的文件,且文件体积很小。
|
|
但这种方式目前来说有缺陷
- 您必须手动将这些大文件基础库,事先 download 至本地。
- node_modules 目录下的 react 库并没什么作用
后续可以考虑自动化的方式实现。